Automatic transaction apparatus, automatic transaction control method, and control program thereof

ABSTRACT

An automatic transaction apparatus operates an automatic transaction unit using middleware whose environment is set by a kernel, which uses conventional middleware even if the interface with the host is standardized. The parameters specific to the vender of the apparatus are set in the parameter file in advance, the I/O control layer edits the parameters of the commands of a common interface (API) and the vender specific parameters of the parameter file, converts the result into the commands of the ATM middle API, sends them to the ATM middleware, and operates the vender specific I/O units.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based upon and claims the benefit of priority fromthe prior Japanese Patent Application No. 2003-390475, filed on Nov. 20,2003, the entire contents of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to an automatic transaction apparatus andautomatic transaction control method for performing automatictransaction operations according to commands from a host, and a controlprogram thereof, and more particularly to an automatic transactionapparatus and automatic transaction control method for enabling theautomatic transaction operation of models with different specificationsusing an interface common with the host, and a control program thereof.

2. Description of the Related Art

Automatic transaction apparatus are used for various transactions, andin the financial field, for example, automatic withdrawal machines andautomatic deposit/withdrawal machines are used, and in other fields,automatic ticket machines and automatic issuing machines are used.

Such an automatic transaction apparatus is normally connected to a host,and deposits/withdrawals, issues tickets and outputs various informationusing a host database. FIG. 37 is a block diagram of a conventionalautomatic transaction system, and shows an ATM (Automatic TellerMachine) for financial operations.

As FIG. 37 shows, the host (server) 300 and the automatic cashtransaction apparatus 400 are connected via a network. The host 300 hasan ATM application layer and a service server for controlling theautomatic transaction apparatus (ATM) 400, and controls the ATM 400using the service server and the ATM application layer.

In the ATM 400, on the other hand, the ATM middleware 410 and the devicedriver 430 operate under the control of the kernel (OS) 420, and I/Ooperations (transaction operations) are performed. The ATM 400 comprisesa card reader/writer unit 440, receipt/journal printer 441, bill/coinprocessing unit 442, passbook processing unit 443 and the customeroperation panel 444 as the I/O mechanism units.

The ATM middleware 410 is an application program for controlling each ofthe above mentioned I/O units according to instructions from the host300, and is comprised of a state layer 412 for interfacing with thehost, an I/O client layer 414 for controlling an individual I/O unit, anI/O server layer 416 for starting and ending an I/O operation andcontrolling the communication protocol, and the I/O service providerlayer 418 for converting messages with each I/O unit.

This ATM middleware 410 is for generating commands and data foroperating each I/O unit according to the instructions from the host 300.Because of this, the ATM middleware 410 is designed according to aspecific interface with the host 300, the configuration of each I/O unit440-444, and vender specific information of the apparatus.

On the other hand, it has been proposed to change the individual setupinformation of the automatic transaction apparatus, such as thefinancial institution number where the apparatus is installed, thebranch number, the host line type and the line speed, via the WEB, usingsuch a protocol as TCP/IP for example (e.g. Japanese Patent ApplicationLaid-Open No. 2002-260068).

In this proposal, fixed setup information, depending on the OS andapplication of the automatic transaction apparatus, can be continuouslyused for a changed OS and application, enabling and guaranteeingcompatibility between different apparatus.

Recently because of demands for an open system, and because of mergersand the integration of the users of financial institutions, there is thedesire to operate multi-model multi-vender automatic transactionapparatus with the same ATM applications (architecture).

In the case of a conventional automatic transaction apparatus, a sameATM middleware 410 can be used if the model and the functional range ofthe automatic transaction apparatus are the same, and if thespecifications of I/O units are the same as well. However, a same ATMmiddleware cannot be used if the model and the functional range of theautomatic transaction apparatus and the specifications of the I/O unitsare different.

For this reason, in order to operate the automatic transaction apparatusfor which the model, functional range and specifications of I/O unitsare different, with the same ATM applications using a common interface,the ATM middleware 410 of an individual automatic transaction apparatusmust be designed accordingly.

Therefore a conventional ATM middleware (asset) cannot be used, and thespread of systems for operating multi-model multi-vender automatictransaction apparatus is being interrupted. In particular this is thecase of increasing the burden of integrating systems when the users offinancial institutions merge.

SUMMARY OF THE INVENTION

With the foregoing in view, it is an object of the present invention toprovide an automatic transaction apparatus and an automatic transactionmethod for operating with a common interface using a conventionalmiddleware asset and a control program thereof.

It is another object of the present invention to provide an automatictransaction apparatus and an automatic transaction control method foreasily customizing a conventional middleware asset according to thearchitecture, and a control program thereof.

It is still another object of the present invention to provide anautomatic transaction apparatus and an automatic transaction controlmethod for increasing the number of models that operate with a commoninterface by using a conventional middleware asset, and a controlprogram thereof.

To achieve these objects, the automatic transaction apparatus of thepresent invention is an automatic transaction apparatus forcommunicating with a host and performing transaction operationsaccording to the operation of the customer, having a plurality of I/Ounits for performing the transaction operations and a control unit forcontrolling the I/O unit according to transaction control signals fromthe host. And the control unit has a middleware layer for operatingunder the control of a kernel and controlling the I/O units, a parameterfile which stores parameters for converting transaction control signalsspecified by an interface with the host into transaction control signalsspecific to the middleware layer, and an I/O control layer forconverting the transaction control signals specified by the interfacewith the host into the transaction control signals specific to themiddleware, referring to the parameter file, and operating themiddleware layer.

The automatic transaction control method of the present invention is anautomatic transaction control method of an automatic transactionapparatus for communicating with a host and performing transactionoperations according to the operation of a customer, having steps of:receiving transaction control signals specified by an interface with thehost; controlling a plurality of I/O units for performing thetransaction operations using a middleware layer based on the transactioncontrol signals; and referring to a parameter file which storesparameters for converting the transaction control signals specified bythe interface with the host into transaction control signals specific tothe middleware, converting the transaction control signals sent from thehost into the transaction control signals specific to the middlewarelayer, and operating the middleware layer.

The control program of the present invention is a control program of anautomatic transaction apparatus for communicating with a host andperforming transaction operations according to the operation of acustomer, for having the automatic transaction apparatus perform stepsof: receiving transaction control signals specified by an interface withsaid host; and referring to a parameter file which stores parameters forconverting the transaction control signals specified by the interfacewith the host into the transaction control signals specific to themiddleware for controlling a plurality of I/O units for performing thetransaction operation, converting the transaction control signals sentfrom the host into the transaction control signals specific to themiddleware layer, and operating the middleware layer.

In the present invention, it is preferable that the I/O control layerhas a plurality of I/O control libraries corresponding to each of theplurality of I/O units, calls up the I/O control library according tothe transaction control signals sent from the host, reads the parameterscorresponding to the I/O control library from the parameter file, editsthe transaction control signal to the transaction control signalsspecific to the middleware layer using the parameter, and operates themiddleware layer.

In the present invention, it is preferable that the middleware layer hasan I/O client layer for intermediating the transaction control signalssent to the I/O unit, an I/O server layer for starting and ending theI/O operation and controlling the communication protocol by thetransaction control signals of the I/O client layer, and an I/O serviceprovider layer for converting messages with each of the I/O units.

In the present invention, it is preferable that the plurality of I/Ounits is a plurality of I/O units that perform cash transactions basedon the operation of the customer.

In the present invention, it is preferable that the I/O control layerreceives the transaction control signals from the host that follows thecash transaction sequence specified by the customer, operates the I/Ounit, and returns it to the host.

In the present invention, it is preferable that the control unit has abrowser for communicating with the host on the WEB, and exchanging thecontrol signals specified by the interface between the I/O control layerand the host.

In the present invention, it is preferable that the I/O control layerlogicalizes the reply from the I/O unit, and relays it to the host.

In the present invention, it is preferable that the I/O unit is an I/Ounit which handles a medium, and the I/O control layer logicalizes thereply regarding the medium from the I/O unit, and replies it to thehost.

According to the present invention, the vender specific parameters ofthe apparatus are set in advance, the I/O control layer edits theparameters of the commands of a common interface (API) and the venderspecific parameters of the parameter file, converts the result into thecommands of the ATM middle API, sends them to the ATM middleware, andoperates the vender specific I/O unit, so the vender specific I/O unitcan be operated by the commands of the common interface (API).

In other words, a conventional ATM middleware can be customized so as tooperate with a standard interface.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an external view depicting an automatic transaction apparatusaccording to an embodiment of the present invention;

FIG. 2 is a block diagram depicting the automatic transaction apparatusin FIG. 1;

FIG. 3 is a system block diagram depicting an automatic transactionsystem according to an embodiment of the present invention;

FIG. 4 is a table showing the transaction commands of the commoninterface in FIG. 3;

FIG. 5 is a block diagram depicting the ATM middleware in FIG. 3;

FIG. 6 is a flow chart (No. 1) depicting the automatic transactioncontrol;

FIG. 7 is a flow chart (No. 2) depicting the automatic transactioncontrol;

FIG. 8 is a diagram depicting the operation according to an embodimentof the present invention;

FIG. 9 is a diagram depicting the operation according to anotherembodiment of the present invention;

FIG. 10 is a table showing a common interface and a vender specificinterface according to an embodiment of the present invention;

FIG. 11 is a flow chart depicting the initialization interfaceconversion processing in the I/O control library;

FIG. 12 is a flow chart depicting the interface conversion processing ofthe passbook insertion processing in the I/O control library;

FIG. 13 is a table showing the vender specific parameters of the card(CRW) unit command;

FIG. 14 is a diagram depicting the card insertion operation;

FIG. 15 is a diagram depicting the card ejection operation;

FIG. 16 is a table showing the vender specific parameters of the bill(BRU) unit command;

FIG. 17 is a diagram depicting the initialization operation of the billunit;

FIG. 18 is a diagram depicting the bill acceptance/counting operation;

FIG. 19 is a diagram depicting the bill storing operation of the billunit;

FIG. 20 is a diagram depicting the bill deposit return;

FIG. 21 is a diagram depicting the bill feeding operation of the billunit;

FIG. 22 is a diagram depicting the bill capturing operation;

FIG. 23 is a diagram depicting the bill releasing operation;

FIG. 24 is a diagram depicting the configuration of the bill unit to bea target;

FIG. 25 is a table showing the vender specific parameters of thepassbook (PPR) unit command;

FIG. 26 is a table showing the vender specific parameters of the receiptprinter (RPR) unit command;

FIG. 27 is a table showing the vender specific parameters of the journalprinter (JPR) unit command;

FIG. 28 is a diagram depicting the passbook insertion operation;

FIG. 29 is a diagram depicting the passbook printing operation;

FIG. 30 is a diagram depicting the passbook MS write operation;

FIG. 31 is a diagram depicting the passbook ejection operation;

FIG. 32 is a diagram depicting the receipt printing operation;

FIG. 33 is a diagram depicting the receipt ejection operation;

FIG. 34 is a diagram depicting the operation of the bill unit fordescribing the logicalization of the unit specific output of the presentinvention;

FIG. 35 is a diagram depicting the first embodiment of thelogicalization processing of the unit specific output of the presentinvention;

FIG. 36 is a diagram depicting the second embodiment of thelogicalization processing of the unit specific output of the presentinvention; and

FIG. 37 is a diagram depicting a conventional automatic transactionsystem.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Embodiments of the present invention will now be described in thesequence of automatic transaction system, common API, customizationmethod for conventional ATM middleware, configuration of I/O controllayer, logicalization method for specific output and other embodiments.

[Automatic Transaction System]

FIG. 1 shows an external view of an automatic transaction apparatusaccording to an embodiment of the present invention, FIG. 2 is a blockdiagram depicting the automatic transaction apparatus in FIG. 1, andFIG. 3 is a system block diagram depicting the automatic transactionsystem according to an embodiment of the present invention.

As FIG. 1 shows, the automatic transaction apparatus 1 has a card entry2 for inserting and ejecting a magnetic card, a passbook entry 3 forinserting and ejecting a magnetic passbook, a bill entry 4 for enteringand ejecting bills, a coin entry 5 for entering and ejecting coins, UOP(User Operation Panel) 6 for a user to operate, an operation display 7for displaying the operation status to the user, and a customer sensor 8for detecting the user.

FIG. 2 is a block diagram depicting the automatic transaction apparatus1 in FIG. 1. The CRW (Card Reader Writer) unit 10 reads the magneticcard by the magnetic head and returns it to the entry 2 whiletransporting the magnetic card inserted from the card entry (cardinsertion slot) 2 using a transport mechanism, which is not illustrated.The CRW unit 10 has an image sensor so as to read the magnetic card(embossed section) optically.

The RPR (Receipt Printer) unit 20 prints the transaction result on thereceipt paper by the print head, and ejects the receipt to the cardentry 2. The RPR unit 20 stores the receipt returned from the entry 2when the ejected receipt is not removed by the user within apredetermined time.

The JPR (Journal Printer) unit 70 prints out the transaction status andthe result on the journal paper by the print head. The UOP unit 30 iscomprised of the UOP (display with touch panel) 6 and the controlcircuit thereof. The passbook processing (PPR) unit 40 reads themagnetic passbook inserted from the passbook entry 3, prints thetransaction on the magnetic passbook, and ejects the passbook from thepassbook entry 3.

The bill/coin processing unit 50 performs deposit operation byvalidating the bills and coins entered through the bill entry 4 and thecoin entry 5, counting them and storing them in stackers, and performswithdrawal operation for taking off the requested bills and coins fromthe cash stacker, and releasing them to the bill entry 4 and the coinentry 5. The control unit 60 is connected to these control units 10, 30,40, 50, and 70 via such a network 90 as a LAN, and performs automatictransaction processing based on the software configuration, which ismentioned later in FIG. 3.

FIG. 3 is a block diagram of the automatic transaction system accordingto an embodiment of the present invention. The automatic transactionapparatus 1 exchanges commands, parameters and data required for thetransaction processing with the WWW (World Wide Web) server (host) 100via such a network 110 as the Internet.

In the automatic transaction apparatus 1, the abovementioned controlunit 60 has the browser 120, ATM middleware 130, kernel (OS) 140 anddevice driver 150.

The device driver 150 is comprised of a card unit driver 151 for drivingthe card (CRW) unit 10, a receipt/journal unit driver 152 for drivingthe receipt/journal unit (RPR/JPR) 20 and 70, a BRU driver 153 fordriving the BRU (bill) unit 50; a CRU driver 154 for driving the CRU(coin) unit 50, a graphic driver 155 and a touch screen driver 156 fordriving the UOP 30, and PPR driver 157 for driving the passbook unit 40.

The browser 120, which is a Web browser, requests the Web server 100 totransmit content, and interprets and displays the content transmitted bythe Web server 100. In this case, the browser 120 requests the contentrequired for the transaction processing which is constructed by HTML andJava (registered trademark), interprets the transmitted content, andcontrols the ATM middleware 130 and the screen of the UOP 30.

The kernel 140 is a known OS (operating system) such as Windows(registered trademark) and Linux, and under the operating environment ofthe kernel 140, the browser 120, ATM middleware 130 and device driver150 operate.

The ATM middleware 130 is comprised of a parameter file 160, I/O controllayer 170, I/O client layer 190, I/O server layer 200 and I/O serviceprocessor layer 210.

This I/O client layer 190 is for controlling an individual I/O unitinstalled in the apparatus, where the I/O server layer 200 starts up andends an I/O operation and controls the communication protocol, and theI/O service provider layer 210 converts the messages with each I/O unit.These are conventional middleware 180, which was designed according tothe functional range and the type of the apparatus, and to thespecifications of the connected I/O unit.

The I/O control layer 170, on the other hand, transmits/receivescommands and data using the middleware common application interfaceprotocol of the Web server 100. Since functional ranges are differenteach other, depending on the model of the apparatus, so the commonapplication interface (API) is comprised of common commands and datasystems that can operate all models, which will be described later inFIG. 4.

The I/O control layer 170 integrates the application interface (API) ofthe I/O client layer 190 and constructs a more abstract common API. Theparameter file 160 is for storing the input parameters/fixed parameterswhich are uniquely determined by the system specifications specific tothe vender (ATM manufacturer).

When the I/O control layer 170 calls up the I/O client layer 190, theI/O control layer 170 calls up the parameters specific to each I/Oclient layer from this parameter file 160, and converts a common APIinto a conventional client API.

By this, the highly abstract common API can be converted into a clientAPI, matching the ATM middleware 190 of the automatic transactionapparatus 1 and the type of the installed I/O unit, and conventional ATMmiddleware 190 and the I/O units can be operated. In other words, aconventional ATM middleware can be customized so as to operate with acommon API.

[Common API]

The common API will be described first. FIG. 4 shows an example of thecommand types of the common API. As CRW (Card Reader/Writer) commands, acard insertion command and a card eject command are provided.

As RPR (Receipt Printer) commands, a print command, release command andother commands are provided. As PPR (Passbook Printer) commands, apassbook insertion command, printing command, MS (Magnetic Stripe) writecommand, passbook ejection command, auto turn page command and othercommands are provided.

As BRU (Bill Recycle Unit) commands, an initialization command,acceptance/counting command, storing command, deposit return command,feeding command, release command, capturing command, transport pathcheck command, jam reset command and other commands are provided. TheCRU (Coin Recycle Unit) commands are the same as the BRU commands, forwhich description is omitted.

The configuration of the ATM middleware 130 will now be described withreference to FIG. 5. The I/O control layer 170 has the I/O controllibrary group 171-178 for controlling each I/O. In this case, the I/Ocontrol library group is comprised of a passbook control library 171,CRW control library 172, ten-key control library 173, receipt controllibrary 174, bill control library 175, coin control library 176, journalcontrol library 177 and transaction control library 178.

These control libraries 171-178 are called up by a task (e.g. cardcontrol EXE) specified by the common API, and converts the task into theclient API of conventional middleware using the above mentionedparameter table 160.

The I/O client layer 190 of the conventional middleware 180 is forcontrolling an individual I/O unit installed in the apparatus, and inthis case, the card (CRW) client 191, coin client 192, bill client 193,RPR client 194, JPR client 195 and PPR client 196 are provided.

In the same way, the I/O server layer 200 is also divided intoindividual I/Os for starting and ending an individual I/O operation, andcontrolling the communication protocol. In other words, the card (CRW)server 201, coin server 203, bill server 202, RPR (Receipt Printer)server 204, JPR server 205 and PPR (Passbook Printer) server 206 aredisposed.

In the same way, the I/O service provider layer 210 is also divided intoindividual I/Os for converting messages with each I/O unit. In otherwords, the card (CRW) service provider 211, coin service provider 213,bill service provider 212, RPR service provider 214, JPR serviceprovider 215 and PPR service provider 216 are provided.

In other words, the control library, client, server and service providerwhich constitute the ATM middleware are provided corresponding to eachI/O unit, and the I/O control 170 converts the requested commands andparameters of the common API into the commands and parameters of theconventional middleware API, and operates the I/O units via theconventional middleware.

Now the relationship of the ATM application program (APL) of the server100, customer operation screen (UOP screen), I/O control and I/O controllibrary will be described using the withdrawal transaction in FIG. 6 andFIG. 7 as an example.

At the start of customer wait processing, the APL of the server 100issues the transaction status setting command to the ATM 1. In the ATM1, the I/O control 170 calls up the transaction control library 178 viaa higher process (e.g. browser), sets the customer wait start status,and displays the customer wait status on the customer operation screenof the UOP 6. Hereafter the transaction control library 178 monitors thedevice status, detects the touch of the customer on the screen of theUOP 6, and reports this to the server 100.

Then the APL of the server 100 performs degradation check processing. Inother words, the APL issues the degradation check command to the ATM 1.In the ATM 1, the I/O control 170 calls up the transaction controllibrary 178 via a higher process (e.g. browser), acquires the devicestatus (status of each I/O unit), then acquires the operation status(e.g. withdrawal only, deposit/withdrawal possible), sets the operationinformation, and reports this setting to the server 100.

The APL of the server 100 issues the transaction type select command andthe screen to the ATM 1 according to the operation information setup bythe transaction type select processing, and the ATM 1 displays thisselect screen on the customer operation screen of the UOP 6.

Since this is an example of the withdrawal transaction, the withdrawalkey of the UOP 6 is pressed, which is reported to the server 100. Bythis, the APL of the server 100 moves to the transaction startprocessing, and issues the transaction start command to the ATM 1. Inthe ATM 1, the I/O control 170 calls up the transaction control library178 via a higher process (e.g. browser), sets the transaction processingstart status, and acquires the transaction information.

Then the APL of the server 100 moves to the card start processing as theacquisition of the transaction information ends, and issues the cardinsertion processing command to the ATM 1. In the ATM 1, the I/O control170 calls up the transaction control library 178 via a higher process(e.g. browser), sets the card insertion processing status, and displaysthe card insertion screen on the customer operation screen of the UOP 6.

And according to the card insertion command, the I/O control 170 callsup the card control library 172, and starts up the card unit 10. Whenthe card unit 10 detects the insertion of the card and reads the card,the card control library 172 notifies the insertion of the card to theAPL of the server 100. And the APL of the server 100 issues thetransaction information acquisition command to the ATM 1, and in the ATM1, the I/O control 170 calls up the transaction control library 178 viaa higher process (e.g. browser), and acquires the transaction status(card insertion detection and card read data in this case).

When the card insertion processing ends, the APL of the server 100 movesto the identification number input processing, and issues theidentification number processing command of the ATM 1. In the ATM 1, theI/O control 170 calls up the ten-key control library 173 via a higherprocess (e.g. browser), and displays the identification number inputscreen on the customer operation screen of the UOP 6. The ten-keycontrol library 173 monitors the ten-key input status of the UOP 6, andnotifies the ten-key input completion to the server 100.

When the ten-key input completes, the APL of the server 100 moves theamount input processing, and issues the amount input processing commandto the ATM 1. In the ATM 1, the I/O control 170 calls up the ten-keycontrol library 173 via a higher process (e.g. browser), and displaysthe amount input screen on the customer operation screen of the UOP 6.The ten-key control library 173 monitors the ten-key input status of theUOP 6, and notifies the ten-key input (amount input, confirmation key)completion to the server 100.

When the amount input processing completes, the APL of the server 100moves to the host communication processing, issues the hostcommunication processing command to the ATM 1, acquires the card data,identification number and the amount from the ATM 1, and displays the“Please Wait” screen on the customer operation screen of the UOP 6.

When the authentication and balance update processing completes, the APLof the server 100 moves to the transaction printing processing, andissues the print command to the ATM 1. In the ATM 1, the I/O control 170calls up the receipt control library 174 via a higher process (e.g.browser), and the receipt printer 20 prints the receipt.

Then the APL of the server 100 moves to the bill feed processing, andissues the bill feed command to the ATM 1. In the ATM 1, the I/O control170 calls up the bill control library 175 via a higher process (e.g.browser), starts up the bill unit 50, and feeds the bill.

When the bill feed processing completes, the APL of the server 100 movesto the medium ejection processing, and issues the medium ejectioncommand to the ATM 1. In the ATM 1, the I/O control 170 calls up thecard control library 172, receipt control library 174 and bill controllibrary 175 via a higher process (e.g. browser), and displays the mediumejection screen on the customer operation screen of the UOP 6. By this,the card is ejected from the card unit 10, the receipt is ejected fromthe receipt printer 20, and the bill is ejected from the bill unit 50.

The APL of the server 100 receives the removal completion notice fromthe ATM 1, moves to the transaction end processing, and issues thetransaction end command to the ATM 1. In the ATM 1, the I/O control 170displays the end screen on the customer operation screen of the UOP 6via a higher process (e.g. browser). At the same time, the I/O control170 sets the transaction status to be processing end in the transactioncontrol library 178, and acquires information of the other controllibraries 171-177. Then the APL of the server 100 returns to the abovementioned customer wait processing.

In this way, the interface of the ATM application of the server 100 andthe ATM 1 can be commonly used for general withdrawal processing,regardless the manufacturer and the model of the ATM 1. By this, aninterface common to each ATM can be constructed. This is the same for adeposit transaction and a balance inquiry.

[Customization Method of Conventional ATM Middleware]

Then modification is necessary so that ATMs can operate with this commoninterface, even if the specifications of the I/O unit and thespecifications of the ATM middleware differ depending on the model ofthe ATM. In this case, designing an ATM middleware itself to match thecommon interfaces decreases the significance of establishing a commoninterface.

Therefore a conventional ATM middleware for operating an I/O unit isutilized and customized so that the ATM can operate with a commoninterface.

FIG. 8 and FIG. 9 are diagrams depicting the operation of an embodimentof the present invention, FIG. 10 is a table showing common interfacesthereof and vender specific interfaces, and FIG. 11 and FIG. 12 are flowcharts depicting the interface conversion processing in the I/O controllibrary.

In FIG. 8 and FIG. 9, the ATM application of the server 100 is a Webapplication, and the CRW (card unit) command and the BRU (bill unit)command with parameters a and b, and A and B are issued as a commoninterface in the ATM applet function call up format of Java (registeredtrademark).

On the other hand in the ATM 1, as described in FIG. 3, the parameterfile 160 stores the input parameters/fixed parameters which are uniquelydetermined by the system specifications of each vender. In FIG. 8, thespecific parameters c and d are stored for the CRW command A, and thespecific parameters C, D and E are stored for the BRU command X as thesetup information specific to the company A.

In the same way, in FIG. 9, the specific parameter c is stored for theCRW command A, and the specific parameters C, D, E and F are stored forthe BRU command X as the setup information specific to the company B.

The I/O control layer 170 calls up the parameter specific to each I/Oclient layer from this parameter file 160 when the ATM middleware 180,including the I/O client layer 190, is called up, and converts thecommon API into the conventional client API.

For example, in FIG. 8, the I/O control layer 170 converts the CRWcommand A (a, b) of the common interface (API) into the command A (a, b,c, d) of the CRW middle API, sends it to the CRW middleware 180, andoperates the CRW unit 10, and also converts the BRU command X (A, B) ofthe common interface (API) into the command X (A, B, C, D, E) of the BRUmiddle API, sends it to the BRU middleware 180, and operates the BRUunit 50.

In the same way, in FIG. 9, the I/O control layer 170 converts the CRWcommand A (a, b) of the common interface (API) into the command A (a, b,c) of the CRW middle API, sends it to the CRW middleware 180, andoperates the CRW unit 10, and also converts the BRU command X (A, B) ofthe common interface (API) into the command X (A, B, C, D, E, F) of theBRU middle API, sends it to the BRU middleware 180, and operates the BRUunit 50.

This will be described using a specific example of the passbookprocessing command in FIG. 10. For the unit initialization command, thevender specific interfaces (parameters) to be used are the passbookprinter user type code, passbook ribbon near end check Yes/Nospecification, passbook MS (Magnetic Stripe) error pause Yes/Nospecification, passbook page mark up and down use Yes/No specification,and page closing Yes/No specification when a forgotten passbook is takenin, which can be specified depending on the specifications of thepassbook unit of each vender.

For the passbook insertion processing command, the common interfaces(parameters) to be provided are the insertion medium logic typespecification, passbook type number specification, W-MS (Wide MagneticStripe) switching specification, stripe position specification, MS eraseYes/No specification, specified line position specification, compositeoperation specification, and camera control (camera is operated when apassbook is inserted) specification.

The vender specific interfaces (parameters) to be provided, on the otherhand, are the MS position specification (e.g. the case when the positionof the MS of the passbook is different depending on the financialinstitution), MS type (recording format), MS parameter (e.g. whether MSdata is erasable), line lamp control specification (when a line lampexists at the passbook entry and the lamp is turned ON at insertion andat ejection).

FIG. 11 is a flow chart depicting the above mentioned unitinitialization processing.

(S10) When the unit initialization command is received, the venderspecific setup information (parameters) on initialization are read fromthe parameter file 160.

(S12) The read parameters are attached to the initialization command,are then sent to the unit, and a reply is received.

FIG. 12 is a flow chart depicting the above mentioned passbook insertionprocessing.

(S20) When the passbook insertion command is received, the venderspecific setup information (parameters) on the passbook information areread from the parameter file 160.

(S22) From the read parameters and the parameters received from thecommon interface (input information), the parameters of the venderspecific unit are edited.

(S24) The edited parameters are attached to the passbook insertioncommand, are then sent to the unit, and a reply is received.

In this way, the vender specific parameters are set in the parameterfile 160 in advance, and the I/O control layer 170 edits the parametersof the command of the common interface (API) and the vender specificparameters of the parameter file 160, converts it into the command ofthe ATM middle API, sends it to the ATM middleware, and operates thevender specific I/O unit 10, so the vender specific I/O unit can beoperated by the command of the common interface (API). In other words,conventional ATM middleware can be customized so as to operate with astandard interface.

[Configuration of I/O Control Layer]

Now each control library of the I/O control layer will be described. Atfirst, the CRW control library will be described. FIG. 13 is a tableshowing the vender specific parameters of the card (CRW) unit command,FIG. 14 is a diagram depicting the card insertion operation, and FIG. 15is a diagram depicting the card ejection operation.

As FIG. 13 shows, for the vender specific parameters of the CRW, theinitialization parameter, ejection parameter, card insertion parameter,MS write parameter, forced ejection parameter and issue parameter areprovided.

The initialization parameter specifies the basic parameters required forthe initialization processing operation of the CRW client. In otherwords, the initial values of the vender specific middleware arespecified. The ejection parameter specifies the parameters required forejecting the medium. For example, the specification on whether the linelamp is turned ON when the medium is ejected is specified.

The card insertion parameter specifies the parameters when specialprocessing is required for inserting a card. The MS write parameterspecifies the parameters required for writing magnetic data to themagnetic stripe of a card. For example, data write availability, and thevender and user specific data are specified.

The force-ejection parameter specifies the parameters required for aforce-ejection of the medium. For example, force-ejection availabilityis specified. The issue parameter specifies the parameters required forissuing a bank transfer card. The specifications of the bank transfercard can be originally determined by the user, where these parameterscan be specified.

FIG. 14 is a diagram depicting the operation of the CRW control library172 and the card unit 10 when the card insertion command is received.When the card insertion command of the common API is received from thebrowser 120, which performs a higher process, the CRW control library172 edits the vender specific parameters and the input parameters, justlike the case of the abovementioned FIG. 12, and issues the cardinsertion command to the card unit 10.

The card unit 10 starts card insertion waiting and notifies the cardinsertion waiting, and when the medium is detected, the card unit 10notifies this to the library 172, and starts taking in the card, and thelibrary 172 notifies the start of the take in operation to the browser120. When the card unit 10 completes the card insertion operation, thecard unit 10 notifies this to the library 172, and extends thisnotification to the browser 120.

When the reading of the magnetic stripe of the card is completed, thecard unit 10 notifies this to the library 172, and extends thisnotification to the browser 120. When the reading of the embossed imageof the card is completed, the card unit 10 notifies this to the library172, and also notifies the completion of insertion to the browser 120.By this, the processing of the card insertion command ends.

FIG. 15 is a diagram depicting the operation of the CRW control library172 and the card unit 10 when the card ejection command is received.When the card ejection command of the common API is received from thebrowser 120, which performs a higher process, the CRW control library172 edits the vender specific parameters and the input parameters, justlike the case of the abovementioned FIG. 12. And if MS update data hasbeen set with the vender specific parameters, then the MS write commandis issued to the card unit 10 as the card ejection command.

The card unit 10 writes the MS and ejects the card. When writing the MScompletes, the card unit 10 notifies this to the library 172. Thelibrary 172 issues the card removal wait command to the card unit 10,and the card unit 10 notifies the start of removal monitoring to thelibrary 172. The library 172 notifies the card removal monitoring startto the browser 120, and the browser 120 starts the removal wait timermonitoring. When the camera specification is “During Ejection”, thelibrary 172 notifies of operation of the monitoring camera to the cardunit 10, and the card unit 10 notifies completion.

When the vender specific parameter indicates flashing at ejection timein the flicker lamp specification, the library 172 instructs theflashing of the flicker lamp to the card unit 10. The card unit 10notifies the completion of processing and removal completion, and alsonotifies card ejection completion to the browser 120. By this, the cardejection command processing ends.

Now the bill control library 175 will be described. FIG. 16 is a tableshowing the vender specific parameters of the bill (BRU) unit command,FIG. 17 is a diagram depicting the initialization processing of the billunit, FIG. 18 is a diagram depicting the bill acceptance/countingoperation, FIG. 19 is a diagram depicting the bill storing operation ofthe bill unit, FIG. 20 is a diagram depicting the bill depositreturning, FIG. 21 is a diagram depicting the bill feeding operation ofthe bill unit, FIG. 22 is a diagram depicting the bill capturingoperation, FIG. 23 is a diagram depicting the bill releasing operation,and FIG. 24 is a block diagram depicting the target bill unit.

As FIG. 24 shows, the bill unit 50 is a bill recycling typedeposit/withdrawal machine, comprising a money entry 500, validationsection 502, pool section 504, bill stackers 505 and 506, collectedmoney storage 508, replenishment money storage 510 and reject box 512.

As FIG. 16 shows, as the vender specific parameters of the BRU, theinitialization parameter, bill acceptance parameter, bill countingparameter, bill acceptance/counting parameter, bill feeding parameter,bill ejection parameter, transport path check parameter and jam resetparameter are provided.

The initialization parameter specifies the basic parameters for theinitialization processing operation of the BRU client. In other words,the initial values of the vender specific middleware are specified. Thebill acceptance parameter specifies the parameters required for waitingfor bill insertion. For example, the alarm during bill insertion waitingYes/No and wait time are specified.

The bill counting parameter specifies the parameters required forvalidating (counting) bills. For example, the maximum number of bills tobe identified is specified. The bill acceptance/counting parameterspecifies the parameters required for waiting for bill insertion andvalidation (counting) of bills.

The bill feeding parameter specifies the parameters required for feedingthe specified denomination, validation (counting) and storing at themoney entry. For example, reject availability is specified. The billrelease parameter specifies the parameters required for releasing billsand the open/close control of the shutter. For example, the shutter opentime and capturing availability are specified.

The transport path check parameter specifies the parameters required fora residual check on the BRU unit transport path. For example, theresidual check position is set. The jam reset parameter specifies theparameters required for collecting jammed bills which are jammed up inthe BRU. For example, the collection destination and retry count ofcollection are specified.

FIG. 17 is a diagram depicting the operation of the bill control library175 and the bill unit 50 when the initialization command is received.When the BRU initialization command of the common API is received fromthe browser 120, which performs a higher process, the bill controllibrary 175 edits the vender specific parameters and the inputparameters, just like the case of the abovementioned FIG. 12, and issuesthe bill unit startup command to the bill unit 50.

The bill unit 50 executes the open processing of the unit, and notifiesthis to the library 175. The library 175 notifies the fixed parameters,including the vender specific parameters, to the bill unit 50, and setsthese parameters. And the library 175 notifies the reset of the billmechanism to the bill unit 50, and when the bill unit 50 completes themechanism reset operation, the bill unit 50 notifies this library 175and the library 175 also notifies the completion of initialization tothe browser 120. By this, the processing of the initialization commandends.

FIG. 18 is a diagram depicting the operation of the bill control library175 and the bill unit 50 when the bill acceptance/counting command isreceived. When the bill acceptance/counting command of the common API isreceived from the browser 120, which performs a higher process, the billcontrol library 175 edits the vender specific parameters and the inputparameters, just like the case of the abovementioned FIG. 12, and issuesthe bill acceptance/counting command to the bill unit 50.

The bill unit 50 opens the money entry 500 (see FIG. 24), notifies theopen completion to the library 175, and the library 175 notifies theopen completion to the browser 120. When the bill unit 50 detects themedium (bill), the bill unit 50 notifies this to the library 175, andextends this notification to the browser 120.

When the bill unit 50 closes the money entry 500, the bill unit 50notifies the close completion to the library 175, and also extends thisnotification the browser 120. When the bill unit 50 starts validation(counting) at the validation section 502, the bill unit 50 notifies thisto the library 175, and extends this notification to the browser 120.When the bill unit 50 stacks the validated bills in the pool section504, the bill unit 50 notifies the stacking completion to the library175, and the library 175 notifies the completion of the billacceptance/counting command to the browser 120. By this, the processingof the bill acceptance/counting command ends.

FIG. 19 is a diagram depicting the operation of the bill control library175 and the bill unit 50 when the bill storing command is received. Whenthe bill storing command of the common API is received from the browser120, which performs a higher process, the bill control library 175 editsthe vender specific parameters and the input parameters, just like thecase of the abovementioned FIG. 12, and issues the bill storing commandto the bill unit 50.

The bill unit 50 stores the bills in the bill stackers 505 and 506 whilecounting the bills in the pool section 504, and when counting completes,the bill unit 50 notifies the counting completion to the library 175,and when storing the bills in the bill storage/stackers 505 and 506completes, the bill unit 50 notifies the storing completion to thelibrary 175. In response to this, the library 175 notifies thecompletion of the bill storing command to the browser 120. By this, theprocessing of the bill storing command is completed.

FIG. 20 is a diagram depicting the operation of the bill control library175 and the bill unit 50 when the bill deposit return command isreceived. When the bill deposit return command of the common API isreceived from the browser 120, which performs a higher process, the billcontrol library 175 edits the vender specific parameters and the inputparameters, just like the case of the above mentioned FIG. 12, andissues the bill deposit return command to the bill unit 50.

The bill unit 50 transports the bills in the pool section 504 to themoney entry 500. When the transport operation is completed, the billunit 50 notifies this to the library 175, and also notifies thecompletion of the bill deposit return to the browser 120. By this, theprocessing of the bill deposit return command ends.

FIG. 21 is a diagram depicting the operation of the bill control library175 and the bill unit 50 when the bill feeding command is received. Whenthe bill feeding command of the common API is received from the browser120, which performs a higher process, the bill control library 175 editsthe vender specific parameters and the input parameters, just like thecase of the abovementioned FIG. 12, and issues the bill feeding commandto the bill unit 50.

The bill unit 50 feeds the bills from the stackers 505 and 506, andtransports them to the money entrance 500 via the validation section502. When the transport operation is completed, the bill unit 50notifies this to the library 175, and also notifies the completion ofthe bill feeding command to the browser 120. By this, the processing ofthe bill deposit return command ends.

FIG. 22 is a diagram depicting the operation of the bill control library175 and the bill unit 50 when the bill capturing command is received.When the bill capturing command of the common API is received from thebrowser 120, which performs a higher process, the bill control library175 edits the vender specific parameters and the input parameters, justlike the case of the abovementioned FIG. 12, and issues the billcapturing command to the bill unit 50.

The bill unit 50 transports the bills from the money entry 500 to aspecified location (e.g. location specified by a vender specificparameters, reject box 512 in the case of FIG. 24). When the transportoperation is completed, the bill unit 50 notifies this to the library175, and also notifies the completion of the bill capturing command tothe browser 120. By this, the processing of the bill capturing commandends.

FIG. 23 is a diagram depicting the operation of the bill control library175 and the bill unit 50 when the bill release command is received. Whenthe bill release command of the common API is received from the browser120, which performs a higher process, the bill control library 175 editsthe vender specific parameters and the input parameters, just like thecase of the abovementioned FIG. 12, and issues the bill release commandto the bill unit 50.

The bill unit 50 opens the money entry 500 (see FIG. 24) and notifiesthe open completion to the library 175, and the library 175 notifies theopen completion to the browser 120. When the bill unit 50 detects thebill removal, the bill unit 50 notifies this to the library 175, andextends this notification to the browser 120.

When the bill unit 50 closes the money entry 500, the bill unit 50notifies the close completion to the library 175, and extends thisnotification to the browser 120. And the library 175 notifies thecompletion of the bill release command to the browser 120. By this, theprocessing of the bill release command ends.

The coin control library 176 also performs a command processing similarto the bill control library 175.

Now the passbook control library 171, receipt control library 174 andjournal control library 177 will be described.

FIG. 25 is a table showing the vender specific parameters of thepassbook (PPR) unit command, FIG. 28 is a diagram depicting the passbookinsertion operation, FIG. 29 is a diagram depicting the passbookprinting operation, FIG. 30 is a diagram depicting the passbook MS writeoperation, and FIG. 31 is a diagram depicting the passbook ejectionoperation.

As FIG. 25 shows, as the vender specific parameters of the PPR, theinitialization parameter, ejection parameter, passbook insertionparameter, force-ejection parameter and issuing parameter are used.

The initialization parameter specifies the basic parameters required forthe initialization processing operation of the PPR client. In otherwords, the initial values of the vender specific middleware arespecified. The ejection parameter specifies the parameters required forejecting the medium. For example, whether the line lamp is turned ON ornot when the medium is ejected is specified.

The passbook insertion parameter specifies the parameters when specialprocessing is required when the passbook is inserted. The force-ejectionparameter specifies the parameters required for a force-eject of themedium. For example, force-ejection availability is specified. Theissuing parameter specifies the parameters required for issuing thepassbook/cut form. For example, a parameter for the user to originallydetermine the specifications of issuing a new passbook or a cut form canbe specified.

FIG. 28 is a diagram depicting the operation of the PPR control library171 and the passbook unit 40 when the passbook insertion command isreceived. When the passbook insertion command of the common API isreceived from the browser 120, which performs a higher process, the PPRcontrol library 171 edits the vender specific parameters and the inputparameters, just like the case of the above-mentioned FIG. 12, andissues the passbook insertion command to the passbook unit 40.

The passbook unit 40 starts passbook insertion waiting, notifies this,and when the medium is detected, the passbook unit 40 notifies this tothe library 171. If it is specified to operate the camera when insertionis started, the library 171 instructs the passbook unit 40 to activatethe monitor camera. The passbook unit 40 notifies the completion of thecamera shot to the library 171, starts taking in the passbook, and thelibrary 171 notifies the start of the take in operation to the browser120. When the passbook unit 40 completes the passbook insertionoperation, the passbook unit 40 notifies this to the library 172, andextends this notification to the browser 120.

When the passbook unit 40 completes the reading of the magnetic stripeof the passbook, the passbook unit 40 notifies this to the library 172,and extends this notification to the browser 120. Also the passbook unit40 reads the page mark of the inserted passbook, and sets the printlines. The passbook unit 40 notifies the completion of setup to thelibrary 172, and also notifies the insertion completion to the browser120. By this, the processing of the passbook insertion command ends.

FIG. 29 is a diagram depicting the operation of the PPR control library171 and the passbook unit 40 when the passbook printing command isreceived. When the passbook printing command of the common API isreceived from the browser 120, which performs a higher process, the PPRcontrol library 171 edits the vender specific parameters and the inputparameters, just like the case of the above-mentioned FIG. 12, andissues the print command to the passbook unit 40.

The passbook unit 40 sequentially prints on the passbook. When it isdetected that the open page of the passbook is fully printed, thelibrary 171 judges whether any print data remains, and if so, thelibrary 171 issues the turn page command to the passbook unit 40, andnotifies this to the browser 120. The passbook unit 40 notifies thecompletion of the turn page command to the library 171, and the library171 issues the printing command to the passbook unit 40 again.

When the passbook unit 40 completes printing on the passbook, thepassbook unit 40 notifies this to the library 171, and also notifies thecompletion of printing to the browser 120. By this, the processing ofthe passbook printing command ends.

FIG. 30 is a diagram depicting the operation of the PPR control library171 and the passbook unit 40 when the passbook MS write command isreceived. When the passbook MS write command of the common API isreceived from the browser 120, which performs a higher process, the PPRcontrol library 171 edits the vender specific parameters and the inputparameters, just like the case of the above mentioned FIG. 12, andissues the MS update command to the passbook unit 40.

The passbook unit 40 updates the magnetic stripe (MS) of the passbook.When the MS update of the passbook is completed, the passbook unit 40notifies this to the library 171, and also notifies the completion ofthe MS update to the browser 120. By this, the processing of thepassbook MS write command ends.

FIG. 31 is a diagram depicting the operation of the PPR control library171 and the passbook unit 40 when the passbook ejection command isreceived. When the passbook ejection command of the common API isreceived from the browser 120, which performs a higher process, the PPRcontrol library 171 edits the vender specific parameters and the inputparameters, just like the case of the above-mentioned FIG. 12. And thelibrary 171 issues the passbook removal wait command to the passbookunit 40, and the passbook unit 40 notifies the removal monitoring startto the library 171.

The library 171 notifies the passbook removal monitoring start to thebrowser 120, and the browser 120 starts removal wait timer monitoring.If the camera specification is “During Ejection”, the library 171notifies the operation of the monitor camera to the passbook unit 40,and the passbook unit 40 notifies completion.

If the specification of the flicker lamp is “Flashing During Ejection”in the vender specific parameters, the library 171 instructs thepassbook unit 40 to flash the flicker lamp. The passbook unit 40notifies the completion of this processing and the completion ofremoval, and also notifies the completion of passbook ejection to thebrowser 120. By this, the processing of the passbook ejection commandends.

FIG. 26 is a table showing the vender specific parameters of the receiptprinter unit command, FIG. 32 is a diagram depicting the receiptprinting operation, and FIG. 33 is a diagram depicting the receiptejection operation.

As FIG. 26 shows, as the vender specific parameters of the receiptprinter (PPR), the initialization parameter and the receipt ejectionparameter are provided.

The initialization parameter specifies the basic parameters required forthe initialization processing operation of the RPR client. In otherwords, the initial values of the vender specific middleware arespecified. The receipt ejection parameter specifies the parametersrequired for receipt ejection. For example, whether the line lamp isturned ON or not when the medium is ejected is specified.

FIG. 32 is a diagram depicting the operation of the RPR control library174 and the receipt printer 20 when the receipt printing command isreceived. When the receipt printing command of the common API isreceived from the browser 120, which performs a higher process, the RPRcontrol library 174 edits the vender specific parameters and the inputparameters, just like the case of the above-mentioned FIG. 12, andissues the printing command to the receipt printer 20.

The receipt printer 20 sequentially prints on the receipt. When printingon the receipt completes, the receipt printer 20 notifies this to thelibrary 174. Also the library 174 issues the overlay command, and causesthe receipt printer 20 to perform overlay printing. When the receiptprinter 20 ends the overlay printing, the library 174 notifies thecompletion of receipt printing to the browser 120. By this, theprocessing of the receipt printing command ends.

FIG. 33 is a diagram depicting the operation of the RPR control library174 and the receipt printer 20 when the receipt ejection command isreceived. When the receipt ejection command of the common API isreceived from the browser 120, which performs a higher process, the RPRcontrol library 174 edits the vender specific parameters and the inputparameters, just like the case of the above mentioned FIG. 12, andissues the receipt ejection command to the receipt printer 20. Thereceipt printer 20 ejects the receipt to the exit, and notifies this tothe library 174.

The library 174 notifies the receipt removal monitoring start to thebrowser 120, and the browser 120 starts removal wait timer monitoring.When the receipt removal is detected, the receipt printer 20 notifiesthe completion of removal to the library 174, and the library 174notifies the completion of receipt ejection to the browser 120. By this,the processing of the receipt ejection command ends.

In this way, the vender specific parameters of the file are read by eachcontrol library, and the common API is converted into the venderspecific API, so a conventional vender specific ATM middleware can becustomized so as to operate with a standard API.

[Logicalization of Vender Specific Output]

When the above mentioned common API is converted into the venderspecific API and the vender specific ATM middleware and I/O units areoperated, the reply output of the vender specific I/O units can also besent to the server 100 with the common API. A method of logicalizing thevender specific output will be described first, using the bill controllibrary 175 of the bill unit 50.

FIG. 34 is a diagram depicting the deposit storing operation of the billunit described in FIG. 19, and FIG. 35 is a diagram depicting thestoring result reply processing of the bill control library 175according to an embodiment of the present invention.

As FIG. 34 shows, in the deposit storing processing, the bills in thepool section 504 pass through the validation section 502, normal billsare stored in the stackers 505 and 506 and in the collected moneystorage 408, and abnormal bills are stored in the reject boxes 512 (A,B) separately.

As FIG. 35 shows, in this vender specific bill unit 50, the storingresult has five types, the number of bills stored in the F (10,000 Yenbills) stacker 505, number of bills stored in the R (1000 Yen bills)stacker 506, number of bills stored in the collected money storage 508,and number of bills stored in the reject box 512 (A) and reject box 512(B).

Here the bill control library 175 receives these five types of outputfrom the bill unit 50, logicalizes them to three types, the number of10,000 Yen bills stored (number of bills in stacker 505), number of 1000Yen bills stored (total number of bills stored in the stacker 506 andnumber of bills stored in the collected money storage 508), and numberof abnormal bills stored (total number of bills stored in the reject box512 (A) and reject box 512 (B)). By this, the difference of the venderspecific storage positions is absorbed, and the information can becommonly notified without consideration of the vender specific storagepositions.

FIG. 36 is a diagram depicting the storing error processing when depositis stored in the bill control library 175 according to anotherembodiment of the present invention. As FIG. 36 shows, a storing erroroccurs when a deposit is stored in the stacker in FIG. 19, and the billsremain on the transport path.

In this vender specific bill unit 50, the medium residual positioninformation has five types, the validation section 502, storingtransport section of the F (10,000 Yen bills) stacker 505, storagetransport section of the R (1000 Yen bills) stacker 506, storingtransport section of the collected money storage 508, and the verticaltransport sections to the reject box 512 (A) and reject box 512 (B).

Here the bill control library 175 receives these five types of outputfrom the bill unit 50, and logicalizes this to the deposited bills aslogical medium residual information. By this, the difference of thevender specific residual positions is absorbed, and the information canbe commonly notifies without consideration of the vender specificresidual positions.

Here the case of bills was described, but logical output is possible inthe same way for the library 176 of the coin unit 50, and logicalizationof the medium residual positions can also be performed by the controllibraries 171 and 172 of the card and passbook.

In this way, the vender specific output of the I/O units can be notifiedto the server 100 with a common API.

Other Embodiments

In the above embodiment, the automatic transaction apparatus shown inFIG. 1 was described as an example, but the present invention can beapplied to other apparatus, such as a withdrawal machine, automaticissue machine, automatic vending machine and automatic cash loanmachine.

The network was described using the Internet, but the present inventioncan also be applied to other networks, and the server can be applied notonly for Web applications but for other applications as well.

The present invention was described using the embodiments, but thepresent invention can be modified in various ways within the scope ofthe essential character of the present invention, which shall not beexcluded from the scope of the present invention.

According to the present invention, the vender specific parameters ofthe file are read and the common API is converted into the venderspecific API, so a conventional vender specific ATM middleware can becustomized so as to operate with a standard API. Therefore an automatictransaction system can be constructed utilizing the conventional assetsof middleware and I/O units, and systems can be easily and quicklyintegrated.

1. An automatic transaction apparatus communicating with a host andperforming a transaction operation according to an operation of acustomer, comprising: a plurality of I/O units performing a financialtransaction operation; and a control unit controlling one of saidplurality of I/O units according to first common transaction controlsignals from said host, and wherein said control unit comprises: amiddleware layer operating according to control of a kernel andcontrolling one of said plurality of I/O units, a parameter file storingparameters to convert said first common transaction control signals,which are common to each apparatus connected to said host and specifiedby an interface with said host, into second transaction control signalsspecific to said middleware layer, and an I/O control layer convertingsaid first common transaction control signals into said secondtransaction control signals specific to said middleware layer byreferring to said parameter file, and operating said middleware layerbased on said second transaction control signals, and wherein saidmiddleware layer specific to said automatic transaction apparatuscontrols said plurality of I/O units performing said financialtransaction operation designated by said first common transactioncontrol signals, according to said second transaction control signals,and wherein each of said of I/O units performing said financialtransaction operation, comprises: a customer operation unit displaying aguidance screen for said customer and inputting a transaction item bysaid operating of said customer, a cash processing unit at leastperforming withdrawal of a cash; and a card reader and writer readingand writing data of a card inserted by said customer, wherein said I/Ocontrol layer converts said first common transaction control signalsspecific to said middleware layer by using said parameter file forinstructing an operation of said customer operation unit, said cashprocessing unit, and said card reader and writer.
 2. The automatictransaction apparatus according to claim 1, wherein: said I/O controllayer further comprises a plurality of I/O control librariescorresponding to each of said plurality of I/O units; and said I/Ocontrol layer calls up one of said plurality of I/O control librariesaccording to said first common transaction control signals from saidhost, reads parameters corresponding to one of said plurality of I/Ocontrol libraries from said parameter file, edits said secondtransaction control signals specific to said middleware layer using theparameters, and operates said middleware layer.
 3. The automatictransaction apparatus according to claim 1, wherein said middlewarelayer comprises: an I/O client layer intermediating third transactioncontrol signals to one of said plurality of I/O units; an I/O serverlayer starting and ending an I/O operation and controlling thecommunication protocol by said third transaction control signals of saidI/O client layer; and an I/O service provider layer converting messageswith each of said plurality of I/O units.
 4. The automatic transactionapparatus according to claim 1, wherein said plurality of I/O unitsimplement cash transactions based on said operation of the customer. 5.The automatic transaction apparatus according to claim 1, wherein saidI/O control layer receives said first common transaction control signalsfrom said host which follow a cash transaction sequence specified bysaid customer, operates one of said plurality of I/O units, and returnsa reply to said host.
 6. The automatic transaction apparatus accordingto claim 1, wherein said control unit further comprises a browsercommunicating with said host on the Web and exchanging said firstcontrol signals specified by the interface between said I/O controllayer and said host.
 7. The automatic transaction apparatus according toclaim 1, wherein said I/O control layer renders logical the reply fromone of said plurality of I/O units and forwards it to said host.
 8. Theautomatic transaction apparatus according to claim 7, wherein: one ofsaid plurality of I/O units is an I/O unit handling a medium; and saidI/O control layer renders logical the reply regarding said medium fromsaid I/O unit, and forwards it to said host.
 9. An automatic transactioncontrol method of an automatic transaction apparatus communication witha host and performing a financial transaction operation according to anoperation of a customer, comprising: receiving first common transactioncontrol signals specified by an interface with said host; controlling aplurality of I/O units performing said financial transaction operationusing a middleware layer based on said first transaction controlsignals; and referring to a parameter file storing parameters to convertsaid first common transaction control signals, which are common to eachapparatus connected to said host and specified by the interface withsaid host, into second transaction control signals specific to saidmiddleware layer, converting said first common transaction controlsignals sent from said host into said second transaction control signalsspecific to said middleware layer, and operating said middleware layerby said second transaction control signals, wherein said controllingcomprises controlling said plurality of I/O units performing saidfinancial transaction operation designated by said first commontransaction control signals, by said middleware layer specific to saidautomatic transaction apparatus operated according to said secondtransaction control signals, and wherein said plurality of I/O unitsperforming said financial transaction operation, comprises: a customeroperation unit displaying a guidance screen for said customer andinputting a transaction item by said operating of said customer; a cashprocessing unit at least performing withdrawal of a cash; and a cardreader and writer reading and writing data of a card inserted by saidcustomer, wherein said converting comprises converting said first commontransaction control signals specific to said middleware layer by usingsaid parameter file for instructing an operation of said customeroperation unit, said cash processing unit, and said card reader andwriter.
 10. The automatic transaction control method according to claim9, wherein said operating step further comprises: calling up an I/Ocontrol library from a plurality of I/O control libraries correspondingto each of said plurality of I/O units according to said first commontransaction control signals from said host; reading parameterscorresponding to said I/O control library from said parameter file; andediting said second transaction control signals specific to saidmiddleware layer by using the parameters, and operating said middlewarelayer.
 11. The automatic transaction control method according to claim9, wherein said control step further comprises controlling one of saidplurality of I/O units by said middleware layer having an I/O clientlayer to intermediate third transaction control signals to one of saidplurality of I/O units, an I/O server layer starting and ending the I/Ooperation and controlling the communication protocol by said thirdtransaction control signals of said I/O client layer, and an I/O serviceprovider layer converting messages with each of said plurality of I/Ounits.
 12. The automatic transaction control method according to claim9, wherein said control step comprises controlling said plurality of I/Ounits to perform cash transactions based on said operation of thecustomer.
 13. The automatic transaction control method according toclaim 12, further comprising returning the operation result of one ofsaid plurality of I/O units according to said first common transactioncontrol signals from said host, which follow the cash transactionsequence specified by said customer, to said host as a reply.
 14. Theautomatic transaction control method according to claim 9, wherein saidreceiving step comprises communicating with said host on the Web andexchanging said first common transaction control signals specified bythe interface with said host.
 15. The automatic transaction controlmethod according to claim 9, further comprising rendering logical thereply from one of said plurality of I/O units, and forwarding it to saidhost.
 16. The automatic transaction control method according to claim15, wherein said reply from one of said plurality of I/O units comprisesrendering logical the reply regarding said medium from one of saidplurality of I/O units handling the medium, and forwarding it to saidhost.
 17. A computer-readable medium storing a control program of anautomatic transaction apparatus communicating with a host and performinga financial transaction operation according to an operation of acustomer, and controlling said automatic transaction apparatus toperform: receiving first common transaction control signals specified byan interface with said host; referring to a parameter file which storesparameters converting said first common transaction control signals,which are common to each apparatus connected to said host and specifiedby the interface with said host, into second transaction control signalsspecific to a middleware layer to control a plurality of I/O unitscomprising a customer operation unit displaying a guidance screen forsaid customer and inputting a transaction item by said operating of saidcustomer, a cash processing unit at least performing withdrawal of acash and a card reader and writer reading and writing data of a cardinserted by said customer, to perform said financial transactionoperation, converting said first transaction control signals, sent fromsaid host, into said second transaction control signals unique to saidmiddleware layer, and operating said middleware layer; and controllingsaid I/O units performing said financial transaction operationdesignated by said first common transaction control signals, by saidmiddleware layer specific to said automatic transaction apparatusoperated according to said second transaction control signals, whereinsaid converting comprises converting said first common transactioncontrol signals into said second transaction control signals specific tosaid middleware layer by using said parameter file for instructing anoperation of said customer operation unit, said cash processing unit,and said card reader and writer.
 18. The computer-readable mediumaccording to claim 17, further controlling said automatic transactionapparatus to perform rendering logical the reply from one of saidplurality of I/O units, and forwarding it to said host.
 19. Theautomatic transaction apparatus according to claim 1, wherein said I/Ocontrol layer converts said first common transaction control signalscomprised of first common commands for said financial transaction intosaid second transaction control signals comprised of second commands andparameters specific to said middleware.
 20. The automatic transactioncontrol method according to claim 9, wherein said converting comprisesconverting said first common transaction control signals comprised offirst common commands for said financial transaction into said secondtransaction control signals comprised of second commands and parametersspecific to said middleware.